home *** CD-ROM | disk | FTP | other *** search
/ Acorn Risc Technologies StrongARM CD-ROM / Acorn Risc Technologies StrongARM CD-ROM.iso / ftp / documents / strongarm / performanc < prev    next >
Encoding:
Text File  |  1996-07-31  |  3.3 KB  |  65 lines
  1. Performance issues
  2. ==================
  3.  
  4. The StrongARM has significantly different performance characteristics to
  5. older ARM processors. It is clocked 5 times faster than any previous ARM,
  6. and many instructions execute in fewer cycles. In particular
  7.  
  8.     *  B/BL take 2 cycles, rather than 3
  9.     *  MOV PC,Rn and ADD PC,PC,Rn,LSL #2 etc take 2 cycles rather than 3
  10.     *  LDR takes 2 cycles (from the cache) rather than 3, and will take
  11.        only 1 cycle if the result is not used in the next instruction.
  12.     *  STR takes 1 cycle rather than 2, if the write buffer isn't full
  13.     *  MUL/MLA take 1-3 cycles rather than 2-17 cycles.
  14.     *  Many instructions will in fact take only one cycle provided the
  15.        result is not used in the next instruction.
  16.  
  17. For fuller information see the StrongARM Technical Reference Manual,
  18. available from Digital Semiconductor's WWW site (currently at
  19. http://www.digital.com/info/semiconductor/dsc-strongarm.html)
  20.  
  21. The StrongARM's cache and write buffer are also significantly better than
  22. previous ARMs, allowing an average fivefold speed increase, despite the
  23. unaltered system bus. Pumping large amounts of data will still be limited
  24. by the system bus, but advantage can be taken of the write buffer to
  25. interleave a large amount of processing with memory accesses. For example
  26. on StrongARM it is quicker to plot a 4bpp sprite to a 32bpp mode than to
  27. plot a 32bpp sprite to a 32bpp mode; the latter case is pure data transfer,
  28. while the former is less data transfer with interleaved (ie effectively
  29. free) processing.
  30.  
  31. The long cache lines of the ARM710 and StrongARM can impact performance.
  32. A random read or instruction fetch from a cached area will load 8 words
  33. into the cache; this can make traversal of a long linked list inefficient.
  34. It is also often worth aligning code to an 8-word boundary. In current
  35. versions of RISC OS modules are loaded at an address 16*n+4. Future
  36. versions of RISC OS will probably load modules at an address 32*n+4, so it
  37. is worth aligning your service call entries appropriately in preparation
  38. for this change.
  39.  
  40. Two significant disadvantages of StrongARM over previous processors
  41. are:
  42.  
  43.     1) Burst reads are not performed from uncached areas. In particular
  44.        this means that reads from the screen are slower on the StrongARM
  45.        than on previous ARMs. A future version of RISC OS may address this
  46.        by marking the screen cacheable before reading (eg in a block copy
  47.        operation). Also, burst writes are not performed to unbuffered
  48.        areas.
  49.        
  50.     2) Code modification is expensive. You can modify code, but a
  51.        complete SynchroniseCodeAreas can take of the order of half
  52.        a millisecond (ie 100000 processor cycles) to execute, and will
  53.        flush the entire instruction cache. Thus use of self-modifying
  54.        code is strongly deprecated; a static alternative will almost
  55.        always be faster. Synchronisation of a single word (eg modifying
  56.        a hardware vector) is cheaper (of the order of 100 processor
  57.        cycles) but still requires the whole instruction cache to be
  58.        flushed.
  59.  
  60. Note that future processors will no doubt have different performance
  61. characteristics again; you shouldn't optimise your code too much for one
  62. particular architecture at the expense of others. However, hopefully you
  63. will now have a better idea how to get better performance from your
  64. StrongARM.
  65.